[登壇レポート] Amazon FSx for Net App ONTAPにおけるファイルシステム/SVM/ボリューム/qtreeの分割の考え方を整理してみる #storagejaws

[登壇レポート] Amazon FSx for Net App ONTAPにおけるファイルシステム/SVM/ボリューム/qtreeの分割の考え方を整理してみる #storagejaws

Clock Icon2024.06.06

どういった単位で各リソースを分割すれば良いのか気になる

こんにちは、のんピ(@non____97)です。

2024年6月5日のStorage-JAWS #4にて、「Amazon FSx for Net App ONTAPにおけるファイルシステム/SVM/ボリューム/qtreeの分割の考え方を整理してみる」というタイトルで登壇しました。

登壇資料

用途や要件を意識してリソースを集約・分割しよう

Amazon FSx for Net App ONTAPにおけるファイルシステム/SVM/ボリューム/qtreeの分割の考え方を紹介をしました。

用途や要件を意識してリソースを集約・分割すると良いでしょう。

FSxNのSSDのミニマムは1TiBです。一環境で必要なストレージサイズが1TiB未満であれば、コスト圧縮のために集約すると良いでしょう。

なお、ボリュームの分割は慎重に行いましょう。ファイルシステムやSVMの構成を見直したい場合は作り直して、ボリュームをSnapMirrorすれば良いです。一方で、ボリューム内のデータをSnapMirrorで分割したり集約したりすることはできません。SnapMirrorを使用せずにボリューム内のデータを移行するのは時間もかかりますし、気にするべき要素が多いです。無用にボリュームを細かく区切りすぎるとSnapMirror relationshipの管理が負担になったり、同時転送数上限に引っかかったりします。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!

参考情報

FSxN全般

ボリューム

qtree

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.